This is a list of work that I can see in the project.  Some of it is my to-do list, other
stuff is things that I can do.  The list is arranged in categories.

---------------------------------------
1. Improving/extending the functionality to the vuGui.
---------------------------------------

d. There is an undesireable behaviour with the opengl canvas.  When you
   scroll, it (1) does not send repaint events to the canvas, and, more
   importantly, (2) draws outside of the canvas and even outside of the
   application.  This is because the Windows drawing device context does not
   get updated, or gets corrupted, for the window. Any workarounds? Might
   have to surf through the wxWindows bugfixes to see if they fixed it,
   or work on it myself.

---------------------------------------
2. Adding extra features to the vuGui.
---------------------------------------

a. Add some fun features to the vuGui, like pressing the spacebar to make
   the glcanvas take up the whole screen.
b. See how the vuGui code would integrate with the wxDesigner.  The
   wxDesigner program is the interactive gui layout tool that comes with
   wxWindows.  It could the easiest for users to lay out their utilities
   using the program.  But how can wxDesigner generated interfaces be
   adapted to the vuGui program?  Do you place unnamed controls, then have
   to go to through the code and replace them as glcanvases?

---------------------------------------
3. Work on the other parts of the tree, and the vuVolume project.
---------------------------------------

a. Work out more of what should be in the volume tree, regarding Steve's
   Splatter code, and what belongs in the gui code.  This is especially to do
   with the initializing opengl,setting up render, and the resize command.  It
   would be ideal to have the vuSplat code simple enough so that it can be 
   implemented with the gui text script.  Right now this would be very 
   complicated.
b. Implement a slicer.  This will also be helpful in showing what other ways
   the vuGui tool might be used.  For example, how about sharing volume data?
   Also with regards to the tree, how does the slicer fit in?
c. Implement some transfer functions and their GUI interfaces.

---------------------------------------
4. Setting up the vuVolume project.
---------------------------------------

a. Folder setup.  The way the project is set up right now might not be the ideal
   way, and might have to be changed later on.  For example, including the different
   header files is a hassle if they're in different directories.  Also, the source
   code is usually split from the headers in most projects.  We can do this by 
   having a vuVolume/include folder and a vuVolume/src folder.
b. Set up for the CVS system.  Before we do this, the directory structure should be
   pretty stable.  One of the quirks of CVS is that changing directories is tricky.
   The CVS server will have to be set up on VolVis, and each computer that 
   needs to access the source will have to have a CVS client.

---------------------------------------
5. Documentation
---------------------------------------

a. Document the gui script.  The basic stuff can be done already, but for most
   of it, I'll have to wait until the tree becomes more stable. This is
   especially to do with #3(a).
b. Start the other documents for the project, namely the programmer documentation
   and the user documentation.

------------------------------------------------------------------------------------
Notes on notes:

4a. There are a few issues with folders:
    -With the vuGui, we might want to separate each of the utilites into separate folders
     to keep the project cleanre.  The problem here is that this creates link issues and
	 makes the makefiles more complicated.  This is the general issue of spllitting source
	 into subfolders.
	-It's probably smarter to name all the source files after their place in the tree. The
	 reason is that we probably can't keep all the object files in seperate directories.
	 This gets ugly when you have to include a lot of them.  Later on, the project might
	 be upgraded to a library.  in this case, the object files might have to have unique
	 names, right?

---------------------------
Things to do:

5. Documentation.  I need to document the vuVolume project..But before I start, is there any further that the vuVolume thing should go..Still would be talk about what the best way to set up the documentation is.

2. Design galleries

Is it appliceable for arbitrary transfer functions and arbitrary render windows?  Try to make it as general as possible and figure out how long it might take to develop it.

6. Finish off the Splat testing window..  Maybe we don't need this anymore though.

1. Hex stuff -- pretty much done.  I'll have to do the rest with Steve.  Also, it might be interesting to try out Marschnerr with both Hex and Reg to see if there really is such a big quality difference.

Is there any work for me to do here?  This stuff is interesting.  Maybe I could try to develop a splatter that works completely on hex arithmetic.  Ie, there would be no more xyz normals, they'd all be hex..Everything would be in hex space until the very final calls to opengl, when we'd translate to cartesian.  Would the quality be the same then?  Also, RLE in hex, what's the best way. Are there any bonuses or subtleties that come out of hex, ie with the normals or geometry?

------------------

Design Galleries for arbitrary transfer functions.

Input vector:  The points needed to specify the transfer function.  In their example, these are the eight control points (the x,y vector), the colour ranges (five values to separate range into six regions), and finally the interval of the intensities.

Output vector: These are properties of the renderred image using the above transfer function.  Since the transfer function affects the image globally, only a few values are needed.  DesGal chooses eight points for each dataset manually.  We might want a more automatic process. For example, we can sample eight or more points randomly in an image to get a sufficiently distributed colour range, then apply these to the rest of the images.  This would save the user the hassle of choosing the points manually.
We'll get three output values per datapoint (RGB colours), giving a total of 24 for DesGal.  This vector can be reduced to a single value by using Euclidean distance between the vectors.

DesGal's heart is finding a set of input vectors that give the widest range of images. This is done using the perturbation algorithm given in the paper.  The starting input array is generated using random values.  They are then perturbed a set number of times.  Again, this process is arbitrary, and can be written for a large number of input parameters. In fact, it can probably be a generic method.

The layout of the thumbnails is done using an MDS scaling matrix.  This part of DesGal is independent of the input and output vectors, and can be applied arbitrarily.

Okay so the parts that are independent of the transfer functions are:
-Everything but the input vector actually.  This has to be set by the transfer function. It can have a getInputNum() method that returns the dimension of the input vector, then the dispersion method can generate an optimal collection of input vectors.

----------------

So the steps are:

1. Supply transfer function, the number of parameters, and the number of vectors to generate / images to have.
   The user has to set the parameters for the Design galleries while setting it up.        Parameters also have to be given for transfer functions, since many of them have a       variable number of arguments.

2. Get the dimension of the input vector from the transfer function class.
  THis is a matter of setting up the proper transfer function abstract base class, and
  then having each transfer function return the values.

3. Generate a complete set of initial random input vectors.
  Generate n*d random numbers, put them together.

4. Apply the dispersion method.  This is strictly mathematical, and actually easily extendeable from the DesGal algorithm.  For each parameter, perturb it.  Then find the distance and that's that.
  Implement the pseudocode from Fig4.  For each dispersion, add +/-c/n to each of the
  elements,then see what happens.

4b. How do you find out what the output vector is for each input?  You have to render the image somehow...Do you render it fullsized, or make it a small thumbnail.hmm
  We don't yet have to make all the thumbnails, but we might as well..  So, generate
  an icon (32*32) image for the output, and compare points from that.  For 32*32, it's
  probably sufficient to sample a random sampling of points.  For each of these, create
  an OpenGL canvas, set at 32*32, and render to that.
  Important Note:  the volume data has to be owned by the main DesGal window, as are
  the GLCanvases I guess.

5. We now have a well dispersed set of input vectors.  Generate the corresponding thumbnails, render them to be pretty small.
  We can keep these from step 4, and just paste GLCanvases to the viewing panel.

6. Apply the MDS scaling matrix to find out the relative x-y positions of each of the thumbnails.

7. Map the thumbnails to a panel that can be zoomed, panned and clicked.
  This can be done by having scroll bars and zoom factors which change the start(x,y)   and end(x,y) position of the panel, then we display all the thumbnaisl there.

8. Finished.

Big questions:
a. Some rendering algorithms change the volume depending on the transfer function..THese cannot be applied to DesGal without doing a lot of reading and memory duplication.  We will have to write slower methods so that the DesGal process is even feasible.

b. How do we apply these different rendering methods?
Is there an adequate base class for all the rendering methods?  On one hand yes:  vuVolume..  Any rendering method will have to implement a render() method...  On the other hand, no:  How do we know that it's not modifying the data in applying the transfer function.  Probably better to rewrite DesGal for each rendering method.

---------------------

What I have to do:

2. Implement the DesGal framework.
3. Implement the GuiStuff.  how? We need
    a. DesGal setup.
    b. DesGal output.
    c. DesGal final editing -- panel, zooms, lines, transfer functino edit.
